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Status of Claims 

1 . This supplemental Office Action is in reply to the amendments filed on 28 October 2009. 

2. Claims 1, 2, 4, 10, 11, 19 and 22 have been amended. 

3. Claims 3, 6 and 23 have been cancelled. 

4. Claims 1,2,4,5 and 7-22 are currently pending and have been examined. 

Response to Amendment 

5. The rejections of claims 1, 2, 4 - 5 and 7-22 under 35 U.S.C. 112, first paragraph are 
maintained for reasons set forth below. 

Response to Arguments 

6. Applicant's arguments received on 28 October 2009 have been fully considered, but they are not 
persuasive and, due to the amendments are moot. Referring to the previous Office action, 
Examiner has cited relevant portions of the references as a means to illustrate the systems as 
taught by the prior art. As a means of providing further clarification as to what is taught by the 
references used in the first Office action, Examiner has expanded the teachings for 
comprehensibility while maintaining the same grounds of rejection of the claims, except as noted 
above in the section labeled "Status of Claims." This information is intended to assist in 
illuminating the teachings of the references while providing evidence that establishes further 
support for the rejections of the claims. 

As noted in the prior Office action, Applicant has attempted to distinguish the claims from 
those taught in the prior art by amending the claims to articulate distinct programs using negative 
limitations, which are generally considered a valid approach to narrowing a claim. Applicant's use 
of the negative limitations however presents several problems as noted in the 35 U.S.C. §112 
rejections below. Notwithstanding those particular issues, the essence of these negative 
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limitations is presented in a host of prior art including Rosnow and others as shown in a 
supported Examiner's Official Notice which describes projects and/or programs managed by 
separate individuals or entities. 

Applicant attempts to traverse the rejection under 35 U.S.C. §112, first paragraph by 
referring to specific portions of the specification. The claim language, specifically "not stored as" 
is very specific and is not disclosed. Examiner believes that the gist of what Applicant attempts to 
convey, is that there is the notion of compartmentalization is large software development projects, 
but this specific notion, if that is indeed all that Applicant attempts to convey, is amply disclosed in 
the prior art noted below. Nonetheless, nowhere in the specification is it stated that program 
activities "are not stored as activities of another program..." or is that degree of specificity 
suggested over and above what is taught in the prior art. 

Although Applicant correctly notes that subject matter need use the same terms 
(Remarks, p. 9), Applicant conveys are very specific notion beyond mere compartmentalization by 
referring to specific acts, i.e., 'storing'. This provides additional, substantive gloss on the notion of 
compartmentalization, hence must be supported in the specification, which it is not. 

Insofar as the rejections under Section 103, Examiner has modified the use of the art and 
has offered several other pieces of prior art in support of Examiner's Official Notice. Finally, and 
as noted earlier, Robson clearly contemplates the notion of a plurality of programs: "According to 
the present invention, the database [ ] may store the tasks, Issues, Change Requests and 
Change Orders for a single project or for multiple projects ." (emphasis added— Robson [9,25]). 
Thus, the prior art of record, does teach and at least renders obvious, the notion of displaying and 
identifying the cross/inter-dependencies between and among tasks of a large and complex project 
and between and among tasks of several large and complex projects. 
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Claim Rejections - 35 USC §112 
First Paragraph 

7. The following is a quotation of the first paragraph of 35 U.S.C. 1 12: 

The specification shall contain a written description of the invention, and of the manner and 
process of making and using it, in such full, clear, concise, and exact terms as to enable any 
person skilled in the art to which it pertains, or with which it is most nearly connected, to 
make and use the same and shall set forth the best mode contemplated by the inventor of 
carrying out his invention. 

8. Claims 1, 2, 4 - 5 and 7-22 are rejected under 35 U.S.C. 112, first paragraph, as failing to 
comply with the written description requirement. The claim(s) contains subject matter which was 
not described in the specification in such a way as to reasonably convey to one skilled in the 
relevant art that the inventor(s), at the time the application was filed, had possession of the 
claimed invention. 

• Independent claims 1,2, 10, 11, 19 and 22 contain the phrases "are not considered activities 
of a larger program" or "are not stored as..." These limitations constitute negative limitations. 
The MPEP states the following with regard to negative limitations: 

"The current view of the courts is that there is nothing inherently ambiguous 
or uncertain about a negative limitation. So long as the boundaries of the 
patent protection sought are set forth definitely, albeit negatively, the claim 
complies with the reguirements of 35 U.S.C. 112, second paragraph ... Any 
negative limitation or exclusionary proviso must have basis in the original 
disclosure. If alternative elements are positively recited in the specification, 
they may be explicitly excluded in the claims. See In re Johnson, 558 F.2d 
1008, 1019, 194 USPQ 187, 196 (CCPA 1977) ("[the] specification, having 
described the whole, necessarily described the part remaining."). See also Ex 
parte Grasselli, 231 USPQ 393 (Bd. App. 1983), aff 'd mem., 738 F.2d 453 
(Fed. Cir. 1984). The mere absence of a positive recitation is not basis for an 
exclusion. Any claim containing a negative limitation which does not have 
basis in the original disclosure should be rejected under 35 U.S.C. 112, first 
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paragraph, as failing to comply with the written description requirement. " 

(MPEP §2173.05(i)) (emphasis added) 
These claims therefore do not satisfy the requirements under 35 U.S.C. §1 12, second 
paragraph, nor do they satisfy the written description requirement under 35 U.S.C. 
§112, first paragraph as the aforementioned limitations are not described in the 
disclosure. 

• Claims 9 and 18 recite the phrase "selected from a group consisting of: phases, 
tasks, deliverables, and gates." The claims contains subject matter which was 
not described in the specification in such a way as to reasonably convey to one 
skilled in the relevant art that the inventor(s), at the time the application was filed, 
had possession of the claimed invention. Specifically, the term "gate" is not 
disclosed in the specification. 

Claim Rejections - 35 USC §103 

9. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all obviousness 

rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or 
described as set forth in section 102 of this title, if the differences between the subject matter 
sought to be patented and the prior art are such that the subject matter as a whole would 
have been obvious at the time the invention was made to a person having ordinary skill in the 
art to which said subject matter pertains. Patentability shall not be negatived by the manner 
in which the invention was made. 

10. Claims 1, 2, 4, 5, 10-14, 16, 19, 20 and 22 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Robson (US 7330822 B1) in view of Pollalis (US 5016170 A) and further in 
view of Examiner's Official Notice. 
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Claims 1, 10, 11, 19 and 22: 

Although claims 1, 10, 11, 19 and 22 are worded and/or structured slightly differently, they have the same 
scope and so are addressed together. Robson, as shown, describes and/or discloses the following 
limitations: 

• receiving at the computer system, an interdependency between a first activity in a first 
program and a second activity in a second program, [...] (Robson, in at least [5,44] states 
"Other dependency relationships may be defined and implemented within the context of 
the present invention [...]") (emphasis added) where 'defining and 'implement[ing]' 
dependency equates to receiving interdependences... See also [9,34-49], the step of 
"storing" and 'defining' a dependency relationship ([9,50]) also corresponds to receiving 
interdependences, and in at least [9,27] refers to "multiple projects" which corresponds to 
from a plurality of programs. Robson [7,52-7] states "Each of the newly defined and 
integrated Tasks, Issues, Change Requests andor Change Orders may be assigned to a 
specific person or entity who may be given primary responsibility for the resolution and 
completion of the newly defined and integrated Task, Issue, Change Request and/or 
Change Order." (emphasis added) where 'assigned to...' is indicative of specified 
programs, hence from a plurality of programs. Note also that Robson [1 ,42] states "Large 
and complex projects may involve hundreds or thousands of people, and are often widely 
distributed, not only across geographical and political boundaries, but also across 
enterprise boundaries and time zones." and thus contemplates the issues of managing 
many individual program or projects managed by many different individuals. Robson 
[5,52] goes on to say that "Large projects, by their very nature, may not be fully definable 
at the project inception. That is, each constituent task of the project may not be defined at 
the start of the project. Problems can and frequently do arise in complex projects, and 
these problems, whether on the project critical path or not, may be interrelated to other 
tasks within the project." This indicates the concept of a project having many interrelated 
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tasks where such tasks could reasonably be denominated as a sub-project with its own 
constituent set of activities.) and; 
• graphically displaying, at the computer system the interdependency between the first 
activity and the second activity in a computerized schedule available to a program 
manage of the first program and a program manager of the second program wherein a 
modification of the first activity in the first program causes an effect of the modification on 
a schedule for the second activity in the second program to be graphically displayed in 
the computerized schedule (Note, Examiner interprets this last limitation as having 
identical scope as the last limitation in claim 10. See above and Robson [5,52] for the 
concepts of several projects and activities. Robson [2,10-12] refers to "improved project 
scheduling tools that enable project contributors to dynamically update the project 
definition and timeline." Robson, in at least [6,27] states: "This ability [...] not only 
enables project managers to manage [...]" (emphasis added) where 'enables project...' 
corresponds to multiple program managers that are 'enabled', hence where the schedule 
[is] available. Robson also refers to the "project schedule" where it is "viewed as a 
computer system configured for managing a project...", hence corresponds to a 
computerized schedule. Robson further states in at least [1,58]: "What are needed, [ ], 
are [...] tools that enable project contributors to dynamically update the project definition 
and timeline." (emphasis added) where this pertains to the 'modification of activities' and 
the 'update' of the related 'schedule'. In claim 10, the modified schedule corresponds to 
the impact of a schedule. Finally, Robson [5,64] makes the notion of sets of activities 
explicit and states "One of the major responsibilities of project managers is to accelerate 
the priority of selected tasks, as it is often only the project manager (or the managers of 
specific portions of the project) that is privy to the macro-level view of the project 
necessary to identify potential problem areas and to take the requisite preemptive 
measures. If unanticipated problems arise and are not integrated within the larger project 
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management framework, critical dates may slip and the timeliness of completion of the 
project may be in jeopardy." (emphasis added, parenthetical in the original).) 
Robson does not specifically disclose graphically displaying said interdependences, but Pollalis, 
in an analogous art, does as shown. In at least the abstract, Pollalis states: "[Ijnformation about 
dependencies in the performance of the tasks are indicated graphically on the display." 
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the features of Robson and Pollalis because Pollalis' system "is interactive, 
readily understandable, capable of generating meaningful visual images which are useful for the 
development of schedules and easily updated. It can be employed to develop an initial schedule, 
monitor progress, generate forecasting information, and manage a project or group activity." 
(Pollalis [2,31]) and thus provides a known technique to improve the utility of Robson and those 
skilled in the art would have recognized that applying the known technique would have yielded an 
improvement that was predictable. 

Neither Robson nor Pollalis specifically teach wherein the first and second programs are 
not stored as activities of another program by the computer system, but Examiner takes Official 
Notice that it is old and well-known as well as common place in the software development arts 
that complex software development projects are typically undertaken by teams of 
developers/programmers and that each team is assigned to work on separate and distinct 
program elements or modules comprising a set of tasks and activities, hence not stored on 
common machines or databases. Such teachings are provided in Robson [1,48] which states 
" Compartmentalization is commonly used to segregate project contributors for a variety of 
reasons, such as to insure security. The consequence of such compartmentalization, however, is 
that project contributors do not have the access required to determine the relative importance of 
the task assigned to them within the project . As most tasks within a project are connected to 
many others, a failure or delay in even a seemingly low-level task may have profound 
repercussions in higher level tasks as the effect of that failure or delay ripples up the project 
hierarchy." (emphasis added). Rosnow [15,44] states "The project planning system includes a 
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knowledge repository as one or more databases in which project information is accumulated as 
projects are completed, dropped from consideration, or put on hold or halted during development. 
Thus, institutional knowledge and experience developed during previous or currently ongoing 
separate projects ..." (emphasis added) and in Kulkarni [0004-8] which describes and/or discloses 
"A real challenge in software development of complex applications, such as business applications 
for example, is that there is no solid tool support in prior-art that enables sufficient automation of 
the development process or that can keep track of parallel operations on independent modules of 
the application that have been assigned to separate team members for development . [...] 
Division of work into units that can be independently developed by a team with guarantees of 
integration." (emphasis added) and in Corral [1,17] which states "Today, however, difficulties 
arise for complex and large-sized organizations when heterogeneous teams work together, i.e. 
teams of different sizes, located in distant geographies, using multiple technologies, wherein 
several developments are conducted in parallel and integrated in a common system, and for 
which the workflow of information is dynamically managed." (emphasis added). While the 
aforementioned art does not specifically recite the claim language of ...programs are not stored 
as activities of another program, this is fairly implied by the context and wording in the above art 
and in view of the nature of the art itself. The above citations using words such as "independent 
modules", "separate team members" and "developments conducted in parallel" reflect the nature 
of complex software development and project management where components are developed 
separately and then integrated. Therefore, it would have been obvious to one of ordinary skill in 
the art at the time the invention was made to combine the teachings of Robson, Pollalis and what 
is old and well-known in the art as all pertain to project management methods used in software 
engineering and providing information pertinent to separate projects or program management by 
separate entities and improves efficiency and reduces the "duplicity of work performed" (Rosnow 
[27,10] inter alia), and such technical methods for combining these teachings existed at the time 
of the invention and the results of such combination was predictable. 
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Claim 2: 

Robson, as shown, describes and/or discloses the following limitations: 

• storing in a database (Robson, in at least [3,39] states: "[l]n a project that includes a plurality 
of interdependent tasks , [...] the database storing : a definition of a first and a second task, a 
status associated with each of the first and second tasks, and a first dependency relationship 
between the first and the second task [ ]" (emphasis added) where the 'database' stores the 
'interdependent tasks' and the 'dependency relationship') (Robson [3,42-4]) cross-program 
dependency information between a first program in the plurality of programs and a second 
program in the plurality of programs, wherein the cross-program dependency information 
includes an interdependency between a first activity in the first program and a second activity 
in the second program, [...] (Robson [5,64] makes the notion of sets of activities explicit and 
states "One of the major responsibilities of project managers is to accelerate the priority of 
selected tasks, as it is often only the project manager (or the managers of specific portions of 
the project) that is privy to the macro-level view of the project necessary to identify potential 
problem areas and to take the requisite preemptive measures. If unanticipated problems 
arise and are not integrated within the larger project management framework, critical dates 
may slip and the timeliness of completion of the project may be in jeopardy." (emphasis 
added, parenthetical in the original) Robson [7,52-7] states "Each of the newly defined and 
integrated Tasks, Issues, Change Requests andor Change Orders may be assigned to a 
specific person or entity who may be given primary responsibility for the resolution and 
completion of the newly defined and integrated Task, Issue, Change Request and/or Change 
Order." (emphasis added) where 'assigned to...' is indicative of specified programs, hence 
from a plurality of programs. Note also that Robson [1,42] states "Large and complex 
projects may involve hundreds or thousands of people, and are often widely distributed, not 
only across geographical and political boundaries, but also across enterprise boundaries and 
time zones." and thus contemplates the issues of managing many individual program or 
projects managed by many different individuals. Robson [5,52] goes on to say that "Large 
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projects, by their very nature, may not be fully definable at the project inception. That is, each 
constituent task of the project may not be defined at the start of the project. Problems can 
and frequently do arise in complex projects, and these problems, whether on the project 
critical path or not, may be interrelated to other tasks within the project." This indicates the 
concept of a project having many interrelated tasks where such tasks could reasonably be 
denominated as a sub-project with its own constituent set of activities.); and 
• graphically displaying, at the computer system, the interdependency between the first activity 
and the second activity in a program schedule wherein a modification of the first activity in the 
first program causes an effect of said modification on a schedule for the second activity in the 
second program to be graphically displayed in the program schedule (Robson [3,8] states "A 
step may be carried out to maintain a selectively and remotely accessible graphical 
representation of the first task, the second task, the first dependency relationship , the defined 
Issue, Change Request and/or the Change Order and/or the second dependency 
relationship, among other items. The selectively and remotely accessible graphical 
representation may be rendered on a Web browser or other interface." (emphasis added) 
and Robson, in at least [6,27] states: "This ability [...] not only enables project managers to 
manage [...]" (emphasis added) where the text refers to multiple program managers that are 
'enabled', hence where the schedule [is] available. Robson also refers to the "project 
schedule" where it is "viewed as a computer system configured for managing a project...", 
hence corresponds to a computerized schedule. Robson further states in at least [1,58]: 
"What are needed, [ ], are [...] tools that enable project contributors to dynamically update the 
project definition and timeline." (emphasis added) where this pertains to the 'modification of 
activities' and the 'update' of the related 'schedule' and corresponds to causes an effect of 
said modification to said program schedule to be displayed. See also Robson [3,25] 
regarding the graphical representation. See the rejection of claim 1 with respect to the notion 
of activities between and among sets of activities.). 
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Robson does not specifically disclose graphically displaying said interdependencies, but Pollalis, 
in an analogous art, does as shown. In at least the abstract, Pollalis states: "[l]nformation about 
dependencies in the performance of the tasks are indicated graphically on the display." 
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention 
was made to combine the features of Robson and Pollalis because Pollalis' system "is interactive, 
readily understandable, capable of generating meaningful visual images which are useful for the 
development of schedules and easily updated. It can be employed to develop an initial schedule, 
monitor progress, generate forecasting information, and manage a project or group activity." 
(Pollalis [2,31]) and thus provides a known technique to improve the utility of Robson and those 
skilled in the art would have recognized that applying the known technique would have yielded an 
improvement that was predictable. 

Neither Robson nor Pollalis specifically teach wherein the first and second programs are 
not stored as activities of another program in the database but Examiner takes Official Notice 
that it is old and well-known as well as common place in the software development arts that 
complex software development projects are typically undertaken by teams of 
developers/programmers and that each team is assigned to work on separate and distinct 
program elements or modules comprising a set of tasks and activities, hence not stored on 
common machines or databases. See the rejection of claim 1 above. Therefore, it would have 
been obvious to one of ordinary skill in the art at the time the invention was made to combine the 
teachings of Robson, Pollalis and what is old and well-known in the art as all pertain to project 
management methods used in software engineering and providing information pertinent to 
separate projects or programs management by separate entities improves efficiency and reduces 
the "duplicity of work performed" (Rosnow [27,10] inter alia), and such technical methods for 
combining these teachings existed at the time of the invention and the results of such 
combination was predictable. 
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Claim 4: 

Robson describes and/or discloses the limitations of claim 1 as shown above. Robson further 
describes and/or discloses the following limitation. 

• said modification initiates an approval request requiring a response before said modification 
(Robson, in at least [0014] states: "[T]o resolve an Issue, the execution of specific steps may 
be required. [...T]he steps required to resolve the Issue may be such as to require some 
level of authorization from some level of the project management team. In such a case, the 
Issue may evolve into (or may be modified to include) a Change Request [...] When and jf 
authorization is obtained to implement the changes [...], the Change Request [ ] may evolve 
into (or be replaced by) a Change Order , [that], identifies the changes or steps that have 
been authorized by the relevant authority to resolve the lssue[...]." (emphasis added) where 
modification of [an] activity is correspondent with 'execution of specific steps' along with 
approval request which is correspondent to a change request' and requiring a response 
before said modification is correspondent with 'if authorization is obtained' and 'authorized by 
the relevant authority'.) 

Claim 5: 

Robson describes and/or discloses the limitations of claim 3 as shown above. Robson further 
describes and/or discloses the following limitation. 

• said modification causes an electronic message to be sent to the program manager of the first 
program and the program manager of the second program (Robson, in at least [7,57] states: 
"The present invention may also advantageously be configured to send a message (such as 
by email , for example) to the person assigned to any given Task, Issue, Change Reguest 
and/or Change Order . The message may be automatically sent via a workflow and Web-based 
system before the due date of the Task, Issue, Change Reguest and/or Change Order to 
remind and/or prompt for changes in the status and estimated completion dates thereof. 
Automated email-based messaging is highly useful [...]." (emphasis added) where the 
emphasized text pertaining to 'email' corresponds to an electronic message and 'to the 
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person...' corresponds to managers of programs as they are typically responsible for 
processing 'change requests'. Robson does not specifically teach that such messages are 
sent between 'program managers' per se, but Robson, as noted above, does teach sending 
messages. Note that this message is 'automatically' sent to "the person assigned" which 
encompasses the task of managing, hence to program managers.) 

Claim 12: 

Robson/Pollalis describes and/or discloses the limitations of claim 11 as shown above. Robson 

further describes and/or discloses the following limitation. 

• The system of Claim 1 1 wherein the modification of one of the first or second activities 
initiates an approval request, said approval request requiring a response before said 
electronic schedule is updated with reestablished interdependencies (Robson, in at least 
the abstract states: "[T]he Change Request identifies step(s) to be taken pending 
authorization to resolve the Issue and the Change Order identifies authorized step(s) to 
do so." (emphasis added) where change reguest' and 'change order' corresponds to 
modification of an activity and 'authorized steps', ipso facto reguires some approval 
response. In [0007], Robson states: "What are needed, therefore, are improved project 
scheduling tools that enable project contributors to dynamically update the project 
definition and timeline ." (emphasis added) where 'contributors' corresponds to entities 
initiating an approval request and 'dynamically update' and 'project definition and 
timeline' correspond to reestablished interdependencies as new project definitions entail 
new project dependencies.) 

Claim 13: 

Robson/Pollalis describes and/or discloses the limitations of claim 11 as shown above. Robson 

further describes and/or discloses the following limitation. 

• The system of Claim 1 1 wherein the modification of one of the first or second activities 
causes an electronic message to be sent the program manager of the first program and 
the program manager of the second program (Robson, in at least [0016] states: 
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" Automated email-based messaging is highly useful when the resolution of one or more 
Tasks, Issues, Change reguests and/or Change Orders depends upon actions of people 
or organizations that are widely scattered across multiple organizations, countries and/or 
time zones." (emphasis added) where 'automated email..." corresponds to an electronic 
message and 'resolutions' that 'depends upon actions of people' together corresponds to 
managers of programs affected by said attempted modification because the resolution is 
ipso facto made by those affected by change reguests or orders. See also the rejection 
of claim 5 above.) 

Claim 14: 

Robson describes and/or discloses the limitations of claim 11 as shown above. Robson further 

describes and/or discloses the following limitation. 

• wherein the electronic schedule has a fixed duration, and wherein if the modification to 
one of the first or second activities causes the fixed duration to change, an electronic 
notification is sent to the program managers of the first and second programs (Robson, 
in at least [1,58] to [2,20] states: "What are needed, therefore, are [...] tools that enable 
project contributors to dynamically update the project definition and timeline [...] to 
update the status of their assigned task [...] in a manner that insures that the overall 
project timeline accurately describes the current status of the entire project [...]." 
(emphasis added) and in at least [7,58] states: "The present invention may also 
advantageously be configured to send a message (such as by email , for example) to the 
person assigned to any given Task, Issue, Change Reguest and/or Change Order." 
(emphasis added) where the 'project timeline' accounts for tasks with fixed duration or 
'anticipated' duration (timeline--see Robson at [1,17] regarding "anticipated timeline") 
and is 'dynamically update[d]' via a 'message' sent by 'email' which corresponds to 
electronic notification. See also the rejection of claim 5.) 



Application/Control Number: 10/694,502 Page 16 

Art Unit: 3624 

Claim 16: 

Robson/Pollalis describes and/or discloses the limitations of claim 11 as shown above. Robson 
further describes and/or discloses the following limitation. 

• said system is a web-based Program Management Application (Robson, in at least 
[0024] states: "As shown [...] the Web-enabled application embodying the present 
invention [...]" (emphasis added).) 

Claim 20: 

Robson/Pollalis describes and/or discloses the limitations of claim 19 as shown above. Robson 
further describes and/or discloses the following limitation. 

• said network is The Internet (Robson, in at least [0011] states: "The computer 
network may include the Internet [. . .]" (emphasis added).) 

11. Claims 9, 18 and 21 are rejected under 35 U.S.C. 103(a) as being unpatentable over Robson (US 
7330822 B1) in view of Pollalis (US 5016170 A) in view of Examiner's Official Notice and further 
in view of Rosnow, et al. (US 7051036 B2). 
Claims 9 and 18: 

Note that although claims 9 and 18 have different dependencies and, hence different preambles, 
they have identical scope and so are addressed together. Robson teaches various types of 
activities such as tasks (Robson [abstract]), deliverables (Robson [6,36]). Robson further 
teaches that several projects may be managed each involving tasks, etc. (Robson [5,64] and 
[9,27]). Robson/Pollalis do not specifically describe and/or disclose the activity 'gates' as in the 
following limitation, but Rosnow, as shown, does. 

• the first and second activities are selected from a group consisting of: phases, tasks, 
deliverables, and gates (Rosnow, in at least [0025] refers to "development phases " 
and "Project data [...] and tasks [...]" (emphasis added). Rosnow, in at least [0039] 
states: "Some of the task deliverables [...]" (emphasis added). Finally, Rosnow refers 
to gates in at least [0010]: "The system [...] prompts decision-makers [...] before 
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proceeding further with the project at predetermined gates of the development 

process." (emphasis added). 
Therefore, it would have been obvious to one with ordinary skill in the art at the time of the 
invention to combine the teachings of Robson/Pollalis with those of Rosnow as they permit a 
variety of different types of activities to be encompassed and handled by project management 
software and systems and thereby enable greater application of the systems and methods 
described in the instant application to complex project management problems. 
Claim 21: 

Robson/Pollalis describes and/or discloses the limitations of claim 19 as shown above. 
Robson/Pollalis do not specifically describe and/or disclose the following limitations, but Rosnow, 
as shown, does. 

• said user interface is a JAVA application (Rosnow [6,51] refers to use of Java script 
for creating a user interface) 

Therefore, it would have been obvious to one with ordinary skill in the art at the time of the invention to 
combine the teachings of Robson/Pollalis with that of Rosnow because, as is widely known, use of Java 
is platform independent, hence "ports well from one operating system to another" (see Application, 
[0034]) and thus provides for greater market penetration and wider adoption of the system and methods 
described. 

12. Claims 7, 8, 15 and 17 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Robson/Pollalis and further in view of Applicant's own prior art. 
Claims 7 and 17: 

Note that although claims 7 and 17 have different dependencies and, hence different preambles 
(where, for example, in claim 7 there is an electronic schedule and in claim 17 there is a system), 
they have identical scope and so are addressed together. Robson describes and/or discloses the 
following limitations as shown above. 

• The method of Claim 1 [11] wherein said computerized schedule is operable by 
program managers to raise issues, alert [other] program managers of scheduling 
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changes, arrange team meetings, and initiate phase exit reviews (Robson, in at least 
the abstract states: " An Issue , a Change Request and/or a Change Order may be 
remotely defined ." (emphasis added) where 'issue' that is 'remotely defined' 
corresponds to raise issues, 'change request' and 'change order' correspond to 
scheduling changes. Robson, in at least [0016] states: "The present invention may 
[...] be configured to send a message (such as by email , for example) to the person 
assigned to any given Task, Issue, Change Reguest and/or Change Order." 
(emphasis added) where 'send a message' via 'email' corresponds to electronic 
schedule [that] is operable and 'the person assigned' to effect a 'change request' 
corresponds to a manager that is alert[ed]V\a email.) 
Robson does not specifically refer to arrange team meetings, and initiate phase exit reviews, but 
Applicant, as shown, does. Applicant in at least [0006] of the description of prior art states: 
"Program management resources include metrics, problem logs, alerts, team meetings, phase 
exit reviews , and audits." (emphasis added). As further shown by the teachings of Robson and 
Pollalis, a great deal of development in project management software systems has occurred over 
the course of many years (from at least the time of Pollalis' invention). As web-enabled 
commerce evolved and more complex projects undertaken, a natural scaling up of project 
management software and systems that permit management across traditional boundaries is 
evident as shown in Robson [1,42]: "Large and complex projects may involve hundreds or 
thousands of people, and are often widely distributed, not only across geographical and political 
boundaries, but also across enterprise boundaries and time zones." 

Therefore, it would have been obvious to one with ordinary skill in the art at the time of 
the invention to combine the teachings of Robson/Pollalis with Applicant's admitted prior art 
thereby providing the capability of establishing tasks and activities, graphically displaying task 
interdependencies, storing such data in a database, and giving managers the capability to view 
and track project developments and otherwise usefully manage complex projects as these 
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combined inventions enable users with greater information and control over an increasingly 
complex project management process involving a multitude of projects. 
Claims 8 and 15: 

Note that although claims 8 and 15 have different dependencies and, hence different preambles, 
they have identical scope and so are addressed together. Robson/Pollalis do not specifically 
describe and/or disclose the following limitation, but Applicant's own prior art, as shown, does. 

• displaying problem logs associated with the computerized [electronic] schedule 
(Applicant in at least [0006] of the description of prior art states: "Program 
management resources include metrics, problem logs , alerts, team meetings, phase 
exit reviews, and audits." (emphasis added). Paragraphs [0007-9] also refer to 
scheduling methods and techniques.) 
As shown by the teachings of Robson and Pollalis, a great deal of development in project 
management software systems has occurred over the course of many years (from at least the 
time of Pollalis' invention). As web-enabled commerce evolved and more complex projects 
undertaken, a natural scaling up of project management software and systems that permit 
management across traditional boundaries is evident. Therefore, it would have been obvious to 
one with ordinary skill in the art at the time of the invention to combine the teachings of 
Robson/Pollalis with Applicant's prior art thereby providing the capability of establishing tasks and 
activities, graphically displaying task interdependencies, storing such data in a database, and 
giving managers the capability to view and track project developments and otherwise usefully 
manage complex projects as these combined inventions enable users with greater information 
and control over an increasingly complex project management process involving a multitude of 
projects 
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Conclusion 

Any inquiry of a general nature or relating to the status of this application or concerning this 
communication or earlier communications from the Examiner should be directed to Mark A. Fleischer 
whose telephone number is 571.270.3925. The Examiner can normally be reached on Monday-Friday, 
9:30am-5:00pm. If attempts to reach the examiner by telephone are unsuccessful, the Examiner's acting 
supervisor, Beth Boswell whose telephone number is 571.272.6737 may be contacted. 

The prior art made of record and not relied upon that is considered pertinent to applicant's disclosure 

are: 

. Kulkarni, et al. (US PgPub 20030028579 A1) 

• Corral (US 7337124 B2) 

. Unite (US 7533033 B1) 

Information regarding the status of an application may be obtained from the Patent Application 
Information Retrieval (PAIR) system. Status information for published applications may be obtained from 
either Private PAIR or Public PAIR. Status information for unpublished applications is available through 
Private PAIR only. For more information about the PAIR system, see 

http://portal.uspto.gov/external/portal/pair <http://pair-direct.uspto.gov >. Should you have questions on 
access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866.217.9197 (toll- 
free). 

Any response to this action should be mailed to: 

Commissioner of Patents and Trademarks 
P.O. Box 1450 
Alexandria, VA 22313-1450 
or faxed to 571-273-8300. 

Hand delivered responses should be brought to the United States Patent and 
Trademark Office Customer Service Window: 

Randolph Building 
401 Dulany Street 
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Alexandria, VA 22314. 

Mark A. Fleischer 
/Mark A Fleischer/ 
Examiner, Art Unit 3624 13 March 2010 

/Beth V. Boswell/ 

Supervisory Patent Examiner, Art Unit 3623 



